Das Entwicklungsteam ist für die Lieferung der Produktfunktionalitäten in der vom Product Owner gewünschten Reihenfolge verantwortlich. Zudem trägt es die Verantwortung für die Einhaltung der vereinbarten Qualitätsstandards.
Das Entwicklungsteam organisiert sich selbst. Es lässt sich von niemandem, auch nicht vom Scrum Master, vorschreiben, wie es Backlogeinträge umzusetzen hat.
Ein Entwicklungsteam sollte in der Lage sein, das Ziel eines jeweiligen Sprints ohne größere äußere Abhängigkeiten zu erreichen. Deshalb ist eine interdisziplinäre Besetzung des Entwicklungsteams wichtig, z. B. mit Architekt, Entwickler, Tester, Dokumentationsexperte und Datenbankexperte.
Gute und schlechte Ergebnisse werden nie auf einzelne Teammitglieder, sondern immer auf das Entwicklungsteam als Einheit zurückgeführt. Das ideale Teammitglied ist sowohl Spezialist als auch Generalist, damit es Teamkollegen beim Erreichen des gemeinsamen Ziels unterstützen kann.
Ein Entwicklungsteam besteht aus mindestens drei, höchstens neun Mitgliedern. Es muss einerseits groß genug sein, alle benötigten Kompetenzen zu vereinigen, andererseits steigt mit wachsender Teamgröße der Koordinierungsaufwand.
Zu den weiteren Aufgaben eines Entwicklungsteams zählt die Schätzung des Umfangs der Einträge im Product Backlog (im Product Backlog Refinement).
Außerdem bricht das Entwicklungsteam in der Sprint Planung die für einen Sprint ausgewählten Einträge aus dem Product Backlog in Arbeitsschritte, sogenannte Tasks, herunter, deren Bearbeitung üblicherweise nicht länger als einen Tag dauert. Das Ergebnis ist das Sprint Backlog.
Team-Mitglieder in Sachsen-Anhalt haben bisweilen Schwierigkeiten, die interdisziplinären Anforderungen zu akzeptieren. So mag beispielsweise ein Entwickler nicht verstehen, warum er auch die Arbeit eines Testers leisten soll.
Dahinter steht jedoch der Gedanke, dass ein starkes Team den Unwägbarkeiten eines Projektes wesentlich besser gewachsen ist als eine Sammlung individueller Talente. Falls jemand mit einer Aufgabe nicht zurecht kommt, kann ein anderer helfen, das Sprint-Ziel zu erreichen. Fällt jemand für einige Zeit aus, so ist ein interdisziplinäres Team besser in der Lage, die fehlende Expertise auszugleichen.
Der Scrum-Prozess
Sprint Planning
Im Sprint Planning werden zwei Fragen beantwortet:
- Was kann im kommenden Sprint entwickelt werden?
- Wie wird die Arbeit im kommenden Sprint erledigt?
Die Sprint-Planung wird daher häufig in zwei Teile geteilt. Sie dauert in Summe maximal 2 Stunden je Sprint-Woche, beispielsweise maximal acht Stunden für einen 4-Wochen-Sprint.
Teil 1: Festlegung des Was
Der Product Owner stellt dem Entwicklungsteam die im Product Backlog festgehaltenen Produkteigenschaften in der zuvor priorisierten Reihenfolge vor.
Das Product Backlog sollte im Sprint zuvor im Product Backlog Refinement so weit vorbereitet worden sein, dass es geordnet, gefüllt und die Einträge für den nächsten Sprint geschätzt sind.
Das gesamte Scrum Team arbeitet im ersten Teil der Planung daran, ein gemeinsames Verständnis für die im Sprint zu erledigende Arbeit zu entwickeln.
Dabei werden die Eigenschaften und die Akzeptanzkriterien besprochen, beispielsweise die Gebrauchstauglichkeit. Außerdem einigt sich der Product Owner mit dem Entwicklungsteam auf die Kriterien, die am Ende des Sprints darüber entscheiden, ob die neue Funktionalität fertig ist oder nicht - siehe Definition of Done.
Ziel ist die Fertigstellung eines auslieferbaren Produkts
Ziel ist die Fertigstellung eines auslieferbaren Produkts: ein Produktinkrement, das hinreichend getestet und integriert ist, um für den Benutzer freigegeben werden zu können.
Anschließend prognostiziert das Entwicklungsteam die Anzahl der Product-Backlog-Einträge, die es im nächsten Sprint liefern kann.
Die Entscheidung, wie viele Einträge im nächsten Sprint umgesetzt werden, liegt alleine beim Team, während die Entscheidung über die Reihenfolge alleine beim Product Owner liegt.
Deshalb müssen beide konstruktiv zusammenarbeiten. Aus den ausgewählten Product-Backlog-Einträgen formuliert das Scrum Team gemeinsam ein Sprintziel.
Die ursprüngliche Beschreibung von Scrum verwendete den Begriff Commitment (Verpflichtung) statt Forecast (Prognose); dies wurde angepasst, weil es häufig zu Fehlentwicklungen zulasten der Qualität führte.
Teil 2: Festlegung des Wie
Im zweiten Teil der Sprint Planung plant das Entwicklungsteam im Detail, welche Aufgaben (Tasks) zum Erreichen des Sprintziels und zur Lieferung der prognostizierten Product-Backlog-Einträge notwendig sind.
Diese Planung macht das Entwicklungsteam, wobei der Product Owner für Fragen in Reichweite sein sollte.
Oftmals bilden sich zur Beantwortung der Wie-Frage Kleingruppen, in denen verschiedene Aspekte wie z. B. Architektur, Datenelemente und Schnittstellen geklärt werden.
Ergebnis ist das Sprint Backlog: der detaillierte Plan für den nächsten Sprint. Er enthält die für den Sprint geplanten Product-Backlog-Einträge und die Aufgaben zu deren Umsetzung. Häufig wird dafür ein Taskboard als Technik verwendet.
Daily Scrum
Zu Beginn eines jeden Arbeitstages trifft sich das Entwicklerteam zu einem max. 15-minütigen Daily Scrum, bei dem Scrum Master und Product Owner häufig anwesend, jedoch nicht aktiv beteiligt sind, falls sie nicht selbst Backlogelemente bearbeiten.
Zweck des Daily Scrum ist der Informationsaustausch.
Im Daily Scrum werden keine Probleme gelöst – vielmehr geht es darum, sich einen Überblick über den aktuellen Stand der Arbeit zu verschaffen. Dazu hat sich bewährt, dass jedes Teammitglied mit Hilfe des Taskboards sagt, was es seit dem letzten Daily Scrum erreicht hat, was es bis zum nächsten Daily Scrum erreichen möchte, und was dabei im Weg steht.
Beim Daily Scrum kann offensichtlich werden, dass die Erledigung einer Aufgabe länger als geplant dauert. Dann ist es sinnvoll, den Task in kleinere Aufgaben aufzuteilen, die dann auch von anderen Mitgliedern des Entwicklungsteams übernommen werden können.
Treten beim Daily Scrum Fragen auf, die sich nicht innerhalb der strikten 15-Minuten-Vorgabe beantworten lassen, so werden sie entweder notiert und dem Scrum Master übergeben, oder ihre Beantwortung wird auf ein späteres Meeting, häufig direkt im Anschluss, verlegt.
Sprint Review
Das Sprint Review steht am Ende des Sprints.
Hier überprüft das Scrum Team das Inkrement, um das Product Backlog bei Bedarf anzupassen.
Das Entwicklungsteam präsentiert seine Ergebnisse und es wird überprüft, ob das zu Beginn gesteckte Ziel erreicht wurde.
Das Scrum Team und die Stakeholder besprechen die Ergebnisse und was als Nächstes zu tun ist.
Im Sprint Review ist die Beteiligung von Kunden und Anwendern wichtig, da diese die fertige Funktionalität des Inkrements benutzen und validieren können.
Hieraus ergibt sich wichtiges Feedback für die weitere Produktgestaltung. Es kann sogar passieren, dass die Funktionalität alle Abnahmekriterien erfüllt und dennoch aus der Perspektive des Benutzers unbrauchbar ist, beispielsweise wenn ein Button an einer schwer auffindbaren Stelle platziert wurde. Häufig entsteht während des Reviews ein lebhafter Dialog, in dem den Anwesenden neue Funktionalitäten einfallen.
Das Ergebnis des Sprint Review ist das vom Product Owner notierte Feedback der Stakeholder. Dies ist eine notwendige Information bei der weiteren Gestaltung des Product Backlogs im nächsten Product Backlog Refinement.
Es ist Aufgabe des Product Owners, die entwickelten Funktionalitäten zu begutachten.
Anhand der im Sprint Planning 1 festgelegten Bedingungen entscheidet er, ob sie abgenommen werden können oder nicht.
Dabei soll er keine Kompromisse eingehen: Ein Team hat auch dann sein Ziel verfehlt, wenn es eine „fast fertige“, aber noch nicht getestete Funktionalität liefert. In diesem Fall kehren die nicht fertiggestellten User Stories in das Product Backlog zurück und werden vom Product Owner neu priorisiert.
Die Abnahme ist aber nicht primärer Gegenstand vom Sprint Review, bei dem es vorrangig um das Feedback der Stakeholder geht.
Die Abnahme der Funktionalitäten des Produktinkrements wird daher häufig im Rahmen des Sprints umgesetzt.
Das Sprint-Review dauert maximal 1 Stunde je Sprint-Woche.
Sprint Retrospektive
Die Sprint Retrospektive steht am Ende eines Sprints.
Hierbei überprüft das Scrum Team seine bisherige Arbeitsweise, um sie in Zukunft effizienter und effektiver zu machen.
Der Scrum Master unterstützt das Scrum Team darin, gute Praktiken und Verbesserungen zu finden, die im nächsten Sprint umgesetzt werden. Die Retrospektive ist eine gemeinsame Aktivität des Scrum Teams.
Das Team soll seine Arbeitsweise offen und ehrlich überprüfen können. Dazu müssen Kritik und unangenehme Wahrheiten offen geäußert werden können. Das schließt auch Gefühle und Empfindungen ein.
Die Retrospektive soll daher in einem geschützten Raum ablaufen. Stakeholder dürfen nur auf Einladung dazukommen. Als Struktur für die Sprint-Retrospektive haben sich fünf Phasen bewährt.
Die Verbesserungsmaßnahmen werden dokumentiert und geplant. Hierfür gibt es unterschiedliche Techniken. Einige Teams nutzen eine eigene Liste mit Hindernissen und Verbesserungsmaßnahmen (das Impediment Backlog), andere Teams nehmen Hindernisse und die entsprechenden Aktivitäten in das Sprint Backlog auf.
Die Sprint-Retrospektive dauert maximal 45 min je Sprint-Woche, also max. drei Stunden für einen 4-Wochen-Sprint.
Product Backlog Refinement
Das Product Backlog Refinement (auch Backlog Grooming genannt) ist ein fortlaufender Prozess, bei dem der Product Owner und das Entwicklungsteam gemeinsam das Product Backlog weiterentwickeln. Hierzu gehören:
- Ordnen der Einträge
- Löschen von Einträgen, die nicht mehr wichtig sind
- Hinzufügen von neuen Einträgen
- Detaillieren von Einträgen
- Zusammenfassen von Einträgen
- Schätzen von Einträgen
- Planung von Releases
Für die Gestaltung des Produkts und des Product Backlogs können Stakeholder wertvolle Informationen liefern, indem sie dem Scrum Team erklären, wie sie sich eine Funktionalität im alltäglichen Gebrauch wünschen. Daher gibt es meistens auch Product-Backlog-Refinement-Treffen zusammen mit ausgewählten Stakeholdern.
Das Product Backlog Refinement sollte nicht mehr als 10 % der Zeit des Entwicklungsteams in Anspruch nehmen.